1. The Field of the Invention
The present invention relates to network technology; and more specifically, to mechanisms for binding a structured data transport to a protocol that offers up data streams such that structured data may be communicated using two-way communications without requiring messages communicated in one direction to be correlated with messages communicated in the opposite direction.
2. Background and Related Art
Computing technology has transformed the way we work and play. Computing systems now take a wide variety of forms including desktop computers, laptop computers, tablet PCs, Personal Digital Assistants (PDAs), household devices and the like. In its most basic form, a computing system includes system memory and one or more processors. Software in the system memory may be executed by the processor to direct the other hardware of the computing system to perform desired functions.
Networking technologies enable computing systems to communicate even over vast distances, thereby expanding on computer functionality. For example, networking technologies enable such applications as e-mail, web browsing, file transfer, instant messaging, electronic whiteboarding, network collaboration, and the like. Accordingly, computer networks enable widespread communication and information access.
Data communicated between computing systems often is in a structured form, where the meaning of the data is implied at least in part by the position of the data within the structure. A software component(s) may generate or interpret at least portions of a data structure by following rules set forth by a structured data protocol. In this description and in the claims, a “structured data protocol” is broadly defined as a set of one or more rules that define how a data structure is to be formed. Potentially, multiple structured data protocols may govern different portions of a data structure.
One example of a structured data protocol includes the various versions of eXtensible Markup Language (XML). XML allows data to be structured in as a hierarchically organized node tree. A root node forms the most ancestral node in the tree. The root node may have zero or more child nodes, with each child node having zero or more child nodes and so forth. Each node has attributes and/or other text context. XML itself does not specify the identity of the node, and also does not specify the form of the hierarchical tree. Accordingly, XML is flexible enough to structurally represent many types of data.
Some structured data protocols impose additional structural rules upon basic XML. Such structured data protocols include, for example, the various versions of Simple Object Access Protocol (SOAP). SOAP defines an XML element in the form of a SOAP envelope, which represents a message that may be bound to a transport. The SOAP envelope includes child XML elements including a headers element, and a body element. The headers element may include some mandatory and optional child XML elements that define versioning, routing, address information, message identifiers, and the like. The body element includes other XML structures that may conform to one or more other structured data protocols.
SOAP is designed to be relatively transport agnostic. However, SOAP defines a default binding to HyperText Transport Protocol (HTTP) as a transport mechanism (often referred to as “SOAP-over-HTTP”). Accordingly, SOAP-over-HTTP is widely implemented. The SOAP-over-HTTP binding (and the underlying HTTP protocol) has a number of limitations that attenuate its utility in client and enterprise scenarios.
First, HTTP is limited in the supported message exchange patterns since HTTP is an inherently request-reply protocol. Specifically, the initiator of an HTTP interaction sends a single request to a service and then waits for a response on the underlying Transmission Control Protocol connection. The response may be ignored thereby simulating a one way communication represented by the request. However, this simulation wastes valuable network bandwidth since the response includes unused information. Accordingly, HTTP only effectively supports the basic single request—single response message exchange pattern. This results in a number of limitations. For instance, a server has no way to send an unsolicited response to a client (i.e., a one-way message). Also, a client may have at most one request pending at a time for a given TCP connection. A second request cannot be initiated until the first response has been received. Furthermore, a server may respond only once to a given request. Finally, because the server is holding a network connection open while processing a request, the time in which the server is to process the message is typically limited, thereby preventing long-running interactions.
Secondly, the deployed HTTP infrastructure does not generally support streaming HTTP request messages. Such streaming of request messages is referred to as “chunking”. This makes it difficult to stream large messages, like multiple megabyte business documents, in a request message. Buffering large messages is generally prohibitively expensive in terms of computer resources.
Thirdly, to activate security with HTTP, an interaction must negotiate from HTTP to the HTTP Secure (HTTPS) protocol. Because HTTPS is a different protocol (with a different TCP port and a different Uniform Resource Identifier (URI) scheme), communication infrastructure generally needs to special-case the negotiation from HTTP to HTTPS. For example, there may be duplicate entries in a routing table; one for supporting HTTP, and one for supporting HTTPS. This is also inefficient in terms of computing resources.
Accordingly, what would be advantageous are mechanisms for binding structured data protocols such as XML and/or SOAP to an underlying transport in a manner that allows for flexible message exchange patterns, that permits data streaming, and that facilitates convenient activation of security.